A large number and variety of software-based medical applications have been developed by academic and commercial entities for use in a variety of areas in the medical field, including patient diagnostics, results reporting, treatment planning, post-procedure follow-up, and clinical operations. Medical applications can, among other things, provide immediate or convenient access to laboratory or imaging tests, provide evidence-based clinical decision-making tools, or address operational efficiencies in healthcare by reducing paperwork or providing logistical support.
For example, information used by a clinician or a specialist for a patient evaluation or consultation is often based on data from one or more prior consultations, or from one or more previous diagnostic tests. However, in certain examples, data collected from one clinician or medical system can be incompatible or incomplete for use by another clinician or medical system. In these examples, the patient could benefit if additional data could be used across different settings in healthcare organizations. Healthcare informatics attempts to deal with this and other problems by merging information science, computer science, and health care to optimize, among other things, the acquisition, storage, retrieval, display, or use of information in healthcare or biomedicine.
In an example, data from a first medical system can be formatted for use by a second medical system. However, creating specific ad-hoc interfaces for each combination of medical systems is largely impractical and a poor solution. Accordingly, medical standards pertaining to the collection, manipulation, or transmission of healthcare information have been developed to improve interoperability between disparate medical systems.
Medical applications typically provide support for at least one medical standard. In certain examples, the support can include an interface for sending or receiving medical data according to one or more applicable medical standard. Examples of medical standards include Digital Imaging and Communications in Medicine (DICOM) or Health Level Seven (HL7), Integrated Healthcare Enterprise (IHE) among others.
For example, DICOM is a standard for handling, storing, printing, or transmitting information in medical imaging. In certain examples, DICOM includes a file and data format definition for medical imaging objects and a network communications and exchange protocol. The communication protocol can include an application protocol that uses TCP/IP to communicate between systems. DICOM files can be exchanged between entities capable of receiving image and patient data in DICOM format.
HL7 is an organization involved in the development of international healthcare standards. The name HL7 is a reference to the seventh application layer of the Open System Interconnection (OSI) model, the highest level where applications communicate with each other. HL7 version 2 defines a series of electronic messages to support administrative, logistical, financial as well as clinical processes. HL7 version 2 has been updated regularly since 1987, resulting in versions 2.1, 2.2, 2.3, 2.3.1, 2.4, 2.5, 2.5.1, and 2.6. Collectively, these versions are known as HL7 version 2.x. Each HL7 v2.x standard is backwards compatible (e.g., a message based on HL7 v2.3 is understood by an application that supports HL7 v2.6). HL7 v2.x uses a textual, non-XML encoding syntax based on delimiters, and can allow interoperability between different electronic healthcare systems, such as Patient Administration Systems (PAS), Electronic Practice Management (EPM) systems, Laboratory Information Systems (LIS), Dietary, Pharmacy and Billing systems, or Electronic Medical Record (EMR) or Electronic Health Record (EHR) systems.
Other examples of medical standards include Integrating the Healthcare Enterprise (IHE), The International Classification of Diseases, 9th Revision (ICD-9), or Continuing Professional Education (CPE).
In addition to supporting medical standards, all commercialized medical applications used in the United States are regulated by the US Food and Drug Administration (FDA) under medical device guidelines as set by federal regulations, such as 21 C.F.R. §820 (2009). Similar regulatory bodies exist for the development and marketing of medical device products in other markets, including countries of the European Union (e.g., UK, Germany, France, Netherlands, Spain, Belgium, Portugal, and Czech Republic), Japan, India, China, South Korea, Australia, and New Zealand. These guidelines are intended to require medical application vendors to implement a quality control system and processes that includes product development (e.g., design controls), labeling, and proper investigation and handling of defects (e.g., complaints, corrective action, preventative action, etc.).
Many US and foreign regulatory bodies also endorse other quality standards, such as ISO 13485, ANSI/AAMI HE74-2001, ANSI/AAMI/ISO 14971, ASTM E1384-07, ASTM E1578, FDA General Principles of Software Validation—Final Guidance for Industry and FDA Staff, IEC 60601-1-1, IEC 62304, ISO 9001:2008, ISO/IEC 12207:2008, ISO/IEC 15026, ISO/IEC 15288:2008, ISO/IEC 27002:2005, ISO/IEC 90003, ISO 9001:200, etc. Many quality standards require that medical applications be tested and validated for their intended use, and that the medical applications be free of defects that can cause harm to patients in their use. In certain examples, compliance is required for both pre-market and post-market approved products. For example, if a product regulated by the FDA has a defect, then the FDA can order the vendor to fix the problem, or the FDA can order the vendor to recall the product and curtail imports until the defect is fixed.
Conventional medical applications are structured in several ways. In a first example, the conventional medical application can be provided as a stand-alone hardware or software product for installation on a client computer at a healthcare site. In this example, the medical application as an executable (.exe) or a set of dynamically linked libraries (.dll) is installed on a dedicated general purpose operating system (e.g. Linux, Microsoft WindowsXP, Microsoft Windows 7, IBM Advanced Interactive eXecutive (AIX), etc.) running on the client computer and interfacing directly with resources (e.g., a physical network interface) of the client computer. Installation begins with a computer having a general-purpose operating system. To build the medical application, a medical application installation process(es) moves files from the installation environment to the disk storage system of the computer system. In addition, the installer processes normally builds a database management system (e.g., Microsoft SQL Server, Oracle, PostgreSQL (Postgres), MySQL, or others) and initializes the database management system using SQL build statements, typically inserting schema, configuration or customer specific data. In certain examples, the install process can also make registry entries or modifications through either regedit or direct editing and replacement of registration entries. When the installation is complete, the system can be tested as a part of the quality assurance and control processes. The environment provided by the client application, or any medical standard parameters (e.g., DICOM Application Entity Titles, TCP/IP addresses and ports, DICOM parameters, etc.), can be configured prior to use.
In a second example, the conventional medical application can be provided for use in a client-server architecture. In this example, a portion of the medical application is installed on a dedicated general purpose operating system (e.g., Linux, Microsoft Windows Server, IBM AIX, etc.) with server management software (e.g., Apache/Tomcat, JBOSS, IIS/ASP etc.) running on at least one server, and another portion of the medical application is installed on one or more client computers. Similar to the stand-alone medical application, the conventional client-server based medical application can be executed within the environment provided by the general-purpose operating systems of the server and client computers and can interface directly with the resources provided by the server and client computers. The installation process in this second example is similar to the first. In certain examples, client computers include installed .exe or .dll files that provide a graphical user interface (GUI) specific to the medical application. The GUI can also provide some bi-directional medical data interface (e.g., Open Database Connectivity (ODBC), Distributed Component Object Model (DCOM), Component Object Model (COM), Simple Object Access Protocol (SOAP), etc.) between the client and server computers. These processes can be repeated for each instance of the medical application installed on the client and server computers.
Either of these first or second examples can be extended to include multi-tenant situations where a medical application accesses one or more remote databases or patient data sources at one or more affiliated or unaffiliated healthcare institutions.
In a third example, the medical application can be executed as a web server application, where the medical data being acted upon is generated at one or more affiliated medical institutions. Web-server software manages user presentation, image viewing, manipulation, or processing, or response to other selectable graphical and line mode oriented input or output. The database and the network and patient data interfaces (e.g., DICOM, HL-7, or IHE-based) of the enterprise web-based environment can be similar to the server components of the client-server environment. This example can be extended to include multi-tenant situations where a medical application accesses one or more remote databases or patient data sources at one or more affiliated or unaffiliated healthcare institutions.